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Title: MANAGEMENT OF PRE-PAID BILLING SYSTEM FOR 

5 WIRELESS COMMUNICATION 

FIELD AND BACKGROUND OF THE INVENTION 

The present invention is of a method and a system for management of pre- 
paid billing for communication systems, and in particular, of such a system and 
10 method for real time pre-paid billing for data transfer in the wireless and wireline 
communication environment. The present application claims priority under 35 
U.S.C. § 1 19 based on U.S. Provisional Application 60/267,413 filed on February 
9,2001. 

Cellular telephones are becoming increasingly popular for portable 
1 5 telephone use, particularly for users who are interested in rapid, mobile data 

communication. As the amount of computational power and memory space which 
are available in such small, portable electronic devices increases, demand arises for 
different types of communication services through such devices. In particular, 
users have demanded that cellular telephones receive many different types of 
20 multimedia data, including e-mail (electronic mail) messages and Web pages. 

In response to such demands, and to extend the power and efficacy of 
operation of portable, wkeless electronic communication devices, the WAP 
(wireless application protocol) standard has been developed. Another such data 
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transfer standard is known as "i-Mode", which is currently used in Japan for data 
transfers, but which is also now being considered for operation in Europe and other 
countries. These data transfer standards enable the subscriber to access the Internet 
through the wireless communication device. In addition, various messaging 
5 standards such as SMS (short messaging service) also exist, and can be used to 
transfer text based messages between wireless communication devices. 

All of these different types of wireless data services are currently provided 
to data-enabled wireless telephones by servers or gateways. Typically, these 
servers or gateways are connected to a wireless telephone network on one side and 

10 to some other network ("external network"), such as the Internet, on the other side. 
For example, an SMSC receives a text message from the Internet or other source 
and sends one or more data packets over a wireless telephone network to a 
particular wireless telephone, which then displays the text message on the wireless 
telephone's display screen. In another example, an HDML or WAP gateway 

15 receives a request generated by a micro-browser in the wireless telephone and 
sends a corresponding request to a server on the Internet. The Internet server 
responds with data, typically formatted according to a markup language, such as 
HDML or WML, and the gateway forwards this data to the micro-browser for 
display on the wireless telephone's screen. Alternatively, the gateway reformats 

20 the data according to a different standard data format before sending the data to the 
wireless telephone. 

Regardless of the particular data transfer standard which is used, a basic 
requirement for effectively operating such services is the ability to appropriately 
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bill the subscriber for these types of services. The current specifications and 
implementations of wireless data network elements do not allow for real-time data 
billing. The actual need may vary, depending on the types of services being offered 
and the role of the operator in offering such services, but the need for a real-time 
5 prepaid data billing solution is evident. 

One example of a system in which such a pre-paid data service billing 
solution would be useful is the GPRS (general packet radio service) system, as 
shown in background art Figure 1. The GPRS architecture features a system 10 
which contains a wireless device 12, which may be a cellular telephone for 

10 example. Wireless device 12 is connected to a base station 14, which contains a 
BSC (base station controller) 16. BSC 16 is in turn in communication with a 
SGSN (serving GPRS support node) 18. SGSN 18 is a network element which is 
responsible for supporting data communication between wireless device 12 
(through BSC 16) and an internal GPRS packet network 20, including packet 

15 routing and transfer, mobility management, logical link management, and 
authentication and charging functions 

Internal GPRS packet network 20 is in turn in communication with a GGSN 
(gateway GPRS support node) 22, which for the purposes of this explanation is an 
example of one implementation of a data gateway, connecting an internal data 

20 network (internal GPRS packet network 20) to an external network, such as the 
Internet 24. GGSN 22 connects GPRS packet network 20 to the Internet 24. 
GGSN 22 communicates with devices connected to the Internet 24 (not shown) 
through such protocols as Radius, and effectively acts as an IP routing platform. 
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GGSN 22 also converts the GPRS packets received from SGSN 18 into the 
appropriate packet data protocol format, such as IP or X.25 for example, as well as 
re-addressing packets received from Internet 24 into the correct address of wireless 
device 12, typically the correct GSM address. 
5 Although background art system 10 operates effectively for the purpose for 

which it was designed, namely the transfer of data between the Internet 24 and 
wireless device 12, background art system 10 unfortunately has a number of 
drawbacks witii regard to billing. As previously described, the network elements of 
background art system 10, such as GGSN 22 and SGSN 18, currently cannot 
1 0 support billing activities. 

There is, therefore, a need for a system for billing for wireless data 
communications that both enables individuals without sufficient credit to engage in 
this type of communication and ensures all data communications are paid for, 
without extending credit to these individuals. 

15 

SUMMARY OF THE INVENTION 

The present invention is a system and method for providing prepaid data 
transfer services to a subscriber through a wireless device. The wireless device is 
connected to a data network for transferring data from a data source, such as the 
20 Internet, for example. A prepaid system monitors the data network in order to 

determine whether a particular requested data transfer service should be authorized, 
for example according to the amoimt available in the account of the subscriber. It 
should be noted that the description of the present invention is discussed in terms 
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of a wireless communication system, however, the present invention can be equally 
applied to wireline communication systems with existing, known wireline 
technologies, without altering the scope of the present invention. 

In one embodiment of the invention, the flow of operations is described as 
5 follows. Firstj the subscriber prepays for service, which can be accomplished 
according to any one of a number of different mechanisms which are known in the 
background art. Next, the subscriber uses a wireless device, such as a cellular 
telephone for example, to access data services, such as SMS or the Internet. The 
request for access is intercepted by the prepaid billing system of the present 

10 invention, which is preferably connected between the extemal network and a 

GGSN, or other gateway, which resides between tlie external network (such as the 
Internet) and the intemal data network (such as an intemal GPRS packet network). 
The prepaid system thereby intercepts data traffic which would otherwise travel 
directly between the external network and the internal data network, as well as 

15 between the wireless device and the extemal network. 

The prepaid system preferably then determines how the data traffic should 
be handled. For example, the prepaid system could optionally selectively allow the 
data traffic to flow, or altematively could discard the traffic, depending on the 
remaining account balance of the subscriber and, optionally, the nature of the 

20 traffic. The prepaid system preferably examines packets representmg requests or 
data flowing from, or to, the wireless device and debits the prepaid account balance 
for the subscriber. According to preferred embodiments of the present invention, 
the calculation of the debit is divided into two parts. According to a fu:st part, the 
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component of the prepaid system which actually receives the request from the user 
calculates the debit in terms of "tokens", which are arbitrary internal units for 
charging for data transfer. Next, in the second part of the calculation process, the 
value of the tokens is converted to a monetary value for debiting the account of the 
5 user, optionally according to particular characteristics of the user. Thus, the 

component of the prepaid system according to the present invention which receives 
the request, such as the data monitor, may optionally not receive any information 
about the user, but only sufficient tokens for the data transfer process to occur. 
Preferably, however, the class of service information is received. 

10 The amount of the debit can depend on the size of the packet or the number 

of packets, for example the account can be debited for each "n" bytes or for each 
page to be displayed. Optionally, the amount of the debit could depend on the type 
of request or data in the packet. For example, request packets might optionally be 
free. Music data might optionally be charged at a lower rate than other kinds of 

15 data packets. Packets with error messages might be free. The amount debited 

might depend on the URL of the destination of the request or the source of the data 
being returned. Some URLs could optionally and preferably be "sponsored", in 
that the owner of the server that handles that URL pays part or all of the cost of 
requests and/or data sent to/from the server. 

20 Optionally, the amount of debit depends upon Uie date and time of the data 

transfer, and the location of the mobile device at the time of transfer, as well as the 

subscriber's class of service (CoS). 

The prepaid system preferably allows packets to be transferred between tlie 

6 
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wireless device and the data service provider (server) only if the subscriber's 
account balance is sufficient and/or if the packets are "free". Optionally and more 
preferably, the system notifies the subscriber when the subscriber's balance is low 
or exhausted, for example via an SMS message or an HDML message sent to the 
5 wireless device. Alternatively, the prepaid system can optionally notify the 
subscriber by sending a message containing a pointer (for example a "recharge 
URL") to a page that contains such a message. 

Heremafter, the term "wireless device" refers to any type of electronic 
device which permits data transmission and/or reception through a wireless 

10 channel, for example through transmission and/or reception of radio waves. 
Hereinafter, the term "cellular telephone" is a wireless device designed for the 
transmission of voice data and/or other data. Non-limiting examples of such data 
include text data, graphical data, audio data, video data, and "documents" 
described in a "mark-up" language. 

1 5 Hereinafter, the term "computational device" includes, but is not limited to, 

any type of wireless device and any type of computer. Examples of wireless 
devices include, but are not limited to, handheld devices, including devices 
operating with the Palm OS®; hand-held computers, PDA (personal data assistant) 
devices, cellular telephones, any type of WAP (wireless application protocol) 

20 enabled device, and wearable computers of any sort, which can be connected to a 
network as previously defined and which have an operating system. 

The present invention could be unplemented in software, firmware or 
hardware. The present invention could be implemented as substantially any type of 
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integrated circuit or other electronic device capable of performing the functions 
described herein. 

In any case, the present invention can be described as a plurality of 
instructions being executed by a data processor, in which the data processor is 
5 understood to be implemented according to whether the present invention is 
implemented as software, hardware or firmware. 



BRIEF DESCRIPTION OF THE DRAWINGS 

The invention is herein described, by way of example only, with reference 
10 to the accompanying drawings, wherein: 

FIG. 1 is a schematic block diagram showing a background system; 

FIG. 2 is a schematic block diagram showing a system according to the 
present invention for pre-paid bilUng of data services; 

FIG. 3 is a schematic block diagram of a system for voice and data 
15 integration according to the present invention; 

FIG. 4 is a schematic block diagram of an exemplary system for voice and 
data transfer according to the present invention; 

FIG. 5 is a schematic block diagram of an alternate exemplary system for 
voice and data transfer according to the present invention; 
20 FIG. 6 is a schematic block diagram of an additional altemate exemplary 

system for voice and data transfer according to the present invention; and 

FIG. 7 is a schematic block diagram of another alternate exemplary system 
for voice and data transfer according to the present invention. 
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DESCRIPTION OF THE PREFERRED EMBODIMENTS 

The present invention will be explained in further detail by making 
reference to the accompanying drawings, which do not limit the scope of the 
5 invention in any way. Again, it should be noted that the application of the present 
invention is not limited to wireless communication systems, but can also be applied 
in wireline communication systems, using existing and known technologies m a 
similar fashion to that disclosed below. 

The present invention is of a system and method for providing prepaid data 

10 transfer services to a subscriber through a wireless device. The wkeless device is 
connected to a data network for transferring data fi:om, or to, a data source, such as 
the Intemet. A prepaid system monitors the data network in order to determine, 
whether a particular requested data transfer service should be authorized, for 
example, according to the amount available in the account of the subscriber. 

15 In one embodiment, the flow of operations is described ?is follows. First, the 

subscriber prepays for service, which can be accomplished according to any one of 
a number of different mechanisms which are known in the background art. Next, 
the subscriber uses a wireless device, such as a cellular telephone for example, to 
access data services, such as SMS or the Internet. The request for access is 

20 intercepted by the prepaid billing system of the present invention, which is 

preferably connected between the external network (for example the Internet 24) 
and GGSN 22, or other gateway which resides between the extemal network and 
the intemal data network (such as an internal GPRS packet network 20). The 
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prepaid system thereby intercepts data traffic which would otherwise travel directly 
between the external network and the internal data network, as well as between the 
wireless device and the external network. 

The prepaid system preferably then determines how the data traffic should 
5 be handled. For example, the prepaid system could optionally selectively allow the 
data traffic to flow, or alternatively could discard the traffic, depending on the 
remaining account balance of the subscriber and, optionally, the nature of the 
traffic. The prepaid system preferably examines packets representing requests or 
data flowing from, or to, the wireless device and debits the prepaid account balance 

10 for the subscriber. According to preferred embodiments of the present invention, 
the calculation of the debit is divided into two parts. In the first part, the 
component of the prepaid system which actually receives the request fi-om the user 
calculates the debit in terms of "tokens", which are arbitrary internal units for 
charging for data transfer. It is noted that although the present discussion involves 

15 a server controlling the billing process, it is also contemplated that the wireless 
device can used and programmed to control or manage the prepaid billing as 
described herein. 

Next, in the second part of the calculation process, the value of the "tokens" 

is converted to a monetary value for debiting the account of the user, optionally 

20 according to particular characteristics of the user. Thus, the component of the 

prepaid system according to the present invention which receives the request, such 

as the data monitor, may optionally not receive any information about the user, but 

only sufficient tokens for the data transfer process to occur. Preferably, however, 

10 
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the class of service information is received. 

The way in which the debit is calculated can vary, and the amount of the 
debit can depend on the size of the packet or the number of packets. For example, 
the account can be debited for each '*n" bytes or for each page to be displayed. 
5 Optionally, the amount of the debit can depend on the type of request or data in the 
packet. For example, request packets might optionally be free. Music data might 
optionally be charged at a lower rate than other kinds of data packets. Packets with 
error messages might be free. The amount debited might depend on the URL of 
the destination of the request or the source of the data being returned. Some URLs 
10 could optionally and preferably be "sponsored", in that the owner of the server lhat 
handles that URL pays part or all of the cost of requests and/or data sent to/from 
the server. 

Additionally, the amount of debit could depend upon the date and time of 
the data transfer, and/or the location of the mobile device at the time of transfer, as 

15 , well as the subscriber's class of service (CoS). 

The prepaid system preferably allows packets to be transferred between the 
wireless device and the data service provider (server) only if the subscriber's 
account balance is sufficient and/or if the packets are "free". Optionally and more 
preferably, the system notifies the subscriber when the subscriber's balance is low 

20 or exhausted, for example via an SMS message or an HDML message sent to the 

wireless device. Alternatively, the prepaid system can optionally notify the 

subscriber by sending a message containing a pointer (for example a "recharge 

URL") to a page that contains such a message. 

11 



wo 02/067600 PCT/US02/01243 

The principles and operation of a method and a system according to the 
present invention may be better understood with reference to the drawings and the 
accompanying description. It is understood that although the present invention is 
described with regard to GPRS, this is for the purposes of description only and is 
5 without any mtention of being limiting, as the present invention would also 

optionally be operative with other data networks, such as CDMA, WCDMA (3G), 
iDen and even Circuit Switched Data, and any other known or used data network. 
Since data monitoring is done between the internal Packet Data Network and the 
Internet (or another external network), the product can work with any such internal 

1 0 Packet Data Network. 

Referring now to the drawings, Figure 2 shows an exemplary 
hnplementation of a system 30 according to the present mvention. System 30 
features a number of the same elements as system 10 of background art Figure 1; 
unless otherwise noted, identically numbered elements have at least the 

15 functionality described with regard to Figure 1. 

System 30 differs from background art system 10 in that system 30 also 
features a data payment server 32, a data monitor 38 and a prepaid server 34. As 
described in greater detail with regard to Figure 3 below, optionally and preferably, 
prepaid server 34 is also in communication with a voice network 36. Data payment 

20 server 32, however, is more preferably only in communication with the data 
transfer elements of system 30. Data payment server 32 is an optional but 
preferred component of system 30 for management of the prepaid system and for 
handling protocols. 

12 
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As shown, prepaid server 34 communicates with data monitor 38 
(optionally through Data Payment Server 32) in order to be able to determine the 
type of data transfer services which are being provided from Internet 24 and/or 
another external network. Data monitor 38 monitors all data traffic from Internet 
5 24 and/or another external network, and reports on a nmnber of characteristics of 
such traffic to prepaid server 34. Such characteristics include, but are not limited 
to, the type of data being transferred and/or the type of data which is requested to 
be transferred, the amount of data being transferred and the identity of the 
subscriber (or wireless device 12) for which the data is being transferred. For 

10 example, request packets might optionally be free. Music data might optionally be 
charged at a lower rate than other kinds of data packets. Packets with error 
messages might be free. Thus, data monitor 38 more preferably calculates the 
charge for the data transfer according to an arbitrary internal unit, which is 
described in greater detail below as a "token", which most preferably does not 

15 require any information about one or more characteristics of the subscriber. 

Prepaid server 34, data payment server 32 and data monitor 38 may 
collectively be termed a "prepaid system", and optionally may also include a DPS 
manager 39 (see below for a description). 

Prepaid server 34 preferably receives the number of tokens, or other 

20 information, from data monitor 38 (optionally through Data Payment Server 32), 

and then calculates the amount of payment which is required for the data transfer to 

occur, more preferably according to at least some of the above characteristics. This 

amount of payment is preferably calculated in terms of actual money to be charged 

13 
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to the account of the subscriber and, therefore, preferably represents a conversion 
from the arbitrary tokens of data monitor 38. 

Optionally, payment could also be calculated according to the date and time 
of day for the transfer. The amount debited might also optionally depend on the 
5 service provider for the data transfer service, such as according to the URL of the 
destination of the request or the source of the data being returned. Some URLs or 
other specific data sources could optionally and preferably be "sponsored", in that 
the owner of the server that handles that URL pays part or all of the cost of 
requests and/or data sent to/from the server (not shown). 

10 According to one embodiment of the present invention, the charging of 

subscribers can be based on, or controlled by, tlie amount of data being transferred 
(which can optionally and preferably include different basic billing blocks, such as 
bytes, kilobytes, images, songs, documents, programs and so forth). Additionally, 
different rates for uplink and downlink can be used. Also, for content-based 

15 billing, differential billing according to such data characteristics as the content type 
of the data (such as WAP or HTTP for example), data protocol (WAP, HTTP, FTP, 
TELNET, POPS, and so forth) and location of the data source (such as the URL for 
WAP and HTTP transfers), can be used, alone or in combination. 

Other preferred features include the ability to determine rates according to 

20 the time of day, the date or other time-based rate information. Service is also 

optionally and more preferably determined according to access control rules for 

different classes of service, which are in tum determined according to one or more 

characteristics of the subscribers. Different subscribers might, therefore, be 

14 
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charged different amounts for the same data, according to their class of service. 
Additionally, special rules are also optionally and more preferably determined for 
secured protocol transfer. 

Further, one optional but particularly preferred feature, of the present 
5 invention, is that data monitor 38 calculates the total amount required for the data 
transfer to occur before such a transfer actually occurs, at the stage when the 
subscriber is sending the request for the data transfer. If such a calculation is 
performed in terms of an arbitrary internal unit such as tokens, then preferably a 
sufficient number of such tokens or other units are received from prepaid server 34, 

10 which then debits the account of the subscriber accordingly. This procedure 

predicts the cost of the transmission and ensures that the subscriber's account can 
afford this predicted cost. Optionally and more preferably, data monitor 38, 
preferably in conjunction with prepaid server 34 (optionally through Data Payment 
Server 32), also calculates the actual amount required for the data transfer as it 

15 actually occurred, since the transfer may not be successful if the connection to the 
data source and/or to wireless device 12 is lost, for example, in which case less 
data is sent than predicted. In other cases, more data is sent than predicted. 

In any case, data monitor 38 sends the required number of tokens to be 
obtained from the account of the subscriber to prepaid server 34 (optionally 

20 through Data Payment Server 32), if data monitor 38 does not have sufficient 

tokens for that particular subscriber. Prepaid server 34 then determines whether the 
accoimt of the subscriber has sufficient funds to cover the requested number of 
tokens. If sufficient funds are available, then prepaid server 34 sends the required 
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tokens to data monitor 38, thereby enabling the transfer to occur, and debits the 
account of the subscriber appropriately. Alternatively, if sufficient funds are not 
available, then prepaid server 34 sends a message to data monitor 38 to block the 
transfer, and does not send the tokens. Such a message is then optionally and more 
5 preferably also sent to the subscriber through wkeless device 12. 

Optionally and more preferably, the subscriber is notified of changes in 
balance and account status while wireless device 12 is engaged in a data transfer. 
Most preferably, the subscriber is notified that access denial is about to occur 
during the data transfer, if the remaining amount in the account of the subscriber is 

10 not sufficient to complete the data transfer. For example, if data monitor 38 
requires tokens for the transfer, but is informed by prepaid server 34 (optionally 
through Data Payment Server 32) that no more tokens can be obtained, then 
preferably this imminent access denial is communicated to the subscriber. 
According to other preferred embodiments of the present invention, the subscriber 

15 is allowed to have a negative amount in the user account, similar to an overdraft at 
a bank, for example in order to permit a data transfer operation to be completed 
even after the prepaid subscriber account has been depleted of fiinds. Such a 
negative amount may optionally be limited according to a "threshold of denial", 
below which the subscriber is denied further service until money is again 

20 transferred into the account 

Also optionally. Call Detail Records (CDRs) are created for data transfers 

for prepaid subscribers. CDRs are records generated and stored in the prepaid 

system. These records provide an audit of charges applied to a subscriber's 

16 
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account. In support of data transfers, these records minimally contain the 
subscriber ID, time, date, charge amount, and type (data transfer) for each charge 
applied. 

According to an exemplary but preferred implementation of the present 
5 invention, each prepaid subscriber receives services according to a specific class of 
a number of different classes, which are defined by the operator. For each class of 
service there are one or more rules, or parameters. 

The parameters for each class of service optionally and more preferably 
include, but are not limited to, the type of service according to various data sources 

10 (identified for example by the destination URL, IP Address or other means), such 
as news, banks and/or other financial institutions for management of financial 
account(s) of the subscriber, games and so forth; the type of protocol which is 
required to deliver the service such as HTTP, FTP, WAP and so forth; the direction 
of data transfer for uplink vs. downlink; the content type such as text, image, 

15 animation, video, audio and so forth; and access permission to any particular type 
of service, defined as permit or deny. The operator is then preferably responsible 
for defining the priority between the different rules of the same class of service. 

One example of such a set of rules is shown in the table below. As shown, 
each rule pertains to a particular class of service (CoS), and may also be 

20 determined according to any one or more of the following characteristics of the 
data transfer: a particular service within the class ("service")^ a particular protocol 
for the data ("protocol"), the direction of data transfer ("up/down"X the type of 
content ("content type"), the status (return code of the application level protocol. 
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such as HTTP "status" return flag), whether access permission is permitted or 
denied, and the weight. The weight is the number of tokens that should be charged 
for every basic billing block of data that matches the specified transfer rules (such 
as Protocol, Content, Status and so forth). The weight is a real number, and is more 
5 preferably permitted to be a j&action, as well as positive, zero or negative. 
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Data monitor 38 is preferably responsible for finding the exact rule which 



matches the data being monitored, and then to calculate a charge for the data 
10 transfer. More preferably, the charge is calculated according to a number of tokens 

to be paid for this data transfer. The calculation is optionally performed according 

to the following equation: 

#Tokens = Weight * Basic Billing Block 

in which the basic billing block is a parameter which is configured by the operator, 
15 and the weight is the amount of such billing blocks which is required to pay for 

each such data transfer service. Each token is thus a basic unit for charging the 

subscriber. Prepaid server 34 determines how much money is available to the 
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subscriber. Data monitor 38 calculates the number of tokens required for each 
transaction and then requests more tokens from prepaid server 34 as necessary 
(optionally through Data Payment Server 32). If sufficient tokens are available, 
then data monitor 38 enables the data transfer to occur. 
5 Prepaid server 34 is, therefore, also responsible for translating the money 

received from the subscriber into tokens, optionally and more preferably according 
to the date, time, location of the mobile station at the time of transfer and 
subscriber's Class of Service. In order to assist communication between data 
monitor 38 and prepaid server 34 (optionally through Data Payment Server 32), a 

10 Token Request and Refund Message is more preferably provided. This message is 
preferably used by data monitor 38 to interact with prepaid server 34 for subscriber 
authentication and token transfers. This message is optionally divided into several 
parts. A first part is the "request tokens" part, which is used to request subscriber 
configuration information and debit a subscriber's account. A "refund tokens" part 

15 is preferably used to refund unused tokens. Both parts can optionally be combined 
in one message. 

The message is optionally used m four different situations. First, when the 

subscriber is trying to connect to the data transfer service, tlie message is used to 

check whether the subscriber is a prepaid user and an initial "chunk" of tokens is 

20 sent to data monitor 38 for the subscriber's use. Next, if the subscriber's credit at 

data monitor 38 is zero, and more tokens are requhed to continue data transfer, the 

message is also preferably sent in order to receive more tokens. In addition, the 

message is used when the previously transmitted tokens have expired, in which 
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case they are refunded and new (fresh) tokens are requested, or when the user 
disconnects. The expiration of tokens occurs at any interval, or at any set time, 
desired by the system operator. Expiration is used to value tokens differently for 
different times of use. For example, on weekends and holidays tokens can be 
5 valued at 40 tokens for $1 .00, whereas nights can be valued at 30 tokens for $1 .00 
and daytime/weekday tokens can be valued at 20 tokens for $1 .00. In the preferred 
embodiment, the prepaid server 34 sends the tokens to the data monitor 38 
(optionally through Data Payment Server 32) with exphation times, so that the data 
monitor 38 send the tokens back to the prepaid server 34 when they expire to 
10 exchange them for "new" tokens reflecting the new value. 

Optionally and most preferably, a DPS manager 39 is provided for 
managing the fiinctions of data payment server 32, data monitor 38 and/or prepaid 
server 34. 

Figure 3 is a schematic block diagram of another preferred embodiment of 

15 the present invention, in which prepaid server 34 handles prepaid services for both 

a voice network 36 and a data network 40. Data network 40 is shown as being 

connected to both the Internet 24 and data monitor 38. In this preferred 

embodiment, prepaid server 34 distributes tokens to both data monitor 38 and voice 

network 36, such that both types of services can optionally be operated on a 

20 prepaid basis. 

In yet another embodiment of the present invention, a slightly different 

billing system is used, particularly when a voice call is being handled by the voice 

network 36. In this embodiment, in addition to the prepaid server 34 handling the 
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prepaid service, the prepaid server 34 monitors the connection of the wireless 
device 12 in the voice network 36, and sends a billing or time record of the 
connection at a set interval durmg the connection. For example, the interval could 
be set to send the connection data every one minute. 
5 This embodiment is particularly useful when, in a voice network 36, there is 

a long connection of voice or data transmission, where it is difficult or impossible 
to determine a proper prepaid amount at the beginning of the cotmection. In 
current data transmission and voice network systems, if the server handUng the 
connection to the wireless device 12 fails before a proper connection hang-up or 

10 disconnect is received, the billing data for the call or data transfer is lost This 
results in a significant amount of connection time being lost and not billed to the 
user. The present embodiment avoids this problem by monitoring the connection 
at a preset interval during the connection and making a record of the connection at 
every occurrence of the interval. 

15 The prepaid server 34 (or any appropriate system platform which is not 

handling the actual connection) monitors and stores the connection or data transfer 
information during the connection at the set interval and continually updates the 
connection records at each occurrence of the preset interval. Therefore, at any one 
given time, if the connection server or system fails before the connection is 

20 properly terminated then only one interval of billing time will be lost. For 

example, if the connection is monitored at one minute intervals and the connection 

is lost at 25 minutes and 52 seconds into the connection, the system will have 

record of at least 25 minutes of connection time, which can be properly billed, 
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whereas in the prior art the entire connection time is lost and remains un-billed. 

The interval to be used can be set at any tune or duration depending on the 
system capabilities and billing requirements of the system operator. For example, 
the connection can be monitored at intervals of 10 seconds, however, this creates a 
5 significant amount of data to be collected and stored during a connection and can 
create a significant burden on some systems (depending on the system capacity). 
This is to be balanced with the billing requirements that are desired. For example, 
if the billing requirements are not as critical (i.e. the time used is not as costly), 
then an interval of one minute, or longer, may be used. 

10 In a preferred embodiment of this aspect of the invention, a code 'tag" is 

added to the Extensible Markup Language (XML) that is used to allow the 
communication of the wireless device 12 to the data network 40 or voice network 
36. (Although it is noted that the present invention is not limited to the use of 
XML and can be used with any commonly known or used wireless markup 

15 language to defme the use of the data received by the wireless device 12.) The 
"tag" or added code triggers the sending of the billmg records of a call or 
connection to a URL, prepaid server 34, or any other location where the 
information is needed for billing, at set mtervals to allow proper billing if the 
connection is lost prior to its proper disconnect. 

20 The use of the present invention will now be discussed with regard to 

exemplary embodiments of a Voice XIVIL system as shown in Figures 4, 5 and 6. 

As shown in these Figures a Voice XML interpreter obtains Voice XML pages 

from any one of web server 1, web server 2, or web server 3. The Voice XML 
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document which is obtained contains a script that is to be interpreted by the Voice 
XML interpreter which results in controlling the Voice XML platform. The Voice 
XML interpreter is connected to the telephony (or communication) subsystem that 
performs speech recognition, play prompt, or any other command required by the 
5 Voice XML interpreter. This results in a user interface session for a telephone, or 
communication subsystem. It is noted that the Voice XML platform and the Voice 
XML interpreter can be a part of the same unit as shown in Figures 5 and 6. The 
firewall is used m the system for security and essentially creates three zones within 
the system. There is a secured zone, protected by the firewall, a "demilitarized" 

10 (DMZ) or neutral zone, partially protected by the firewall, and the internet. It is 
noted that the DMZ, or neutral zone, is generally located between a private 
network (behind a firewall) and the internet to allow users of the internet to access 
one or at least some of a web provider's servers, while keeping some of the private 
servers off-limits behind a firewall. The web server from which the information, or 

15 web page, is to be obtained (i.e. web servers 1, 2 or 3) can be located in anyone of 
the three zones, as shown in Figures 4-6. When presenting information services, 
either the Voice XML interpreter or Voice XML platform can access a web server 
(1-3), file server, or any other source of data to get the requested or needed data. 
In the present invention, the Voice XML platform (or equivalent platform) 

20 will, according to its configuration, be able to determme, or would know, which 

operations or data requests require billing and those that would not. The 

configuration can also indicate that a TarifiF engine should be "consulted" for every 

operation and the returned answer fi:om the prepaid system will determine whether 
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to, and how much to bill. Essentially, when the Tariff engine is "consulted" the 
system sends a query to a pre-determined address according to a pre-set of rules 
and receives instructions on how to proceed. This can be alternatively referred to 
as a "manual" mode as the system does not automatically calculate tiie cost, but 
5 waits for instruction. For each operation which requires billing the system will 
access the prepaid system (which can be configured and operate as the prepaid 
server 34 shown in Figure 2 and previously discussed) via the Tariff engine, and 
will request a certam amount of time to give the requested service. It is detemiined 
whether or not such time is available, and then if the time is available the operation 

10 proceeds. When the duration of the of the requested amount of time is near its end 
(about to elapse) the Voice XML platform will ask for an additional amount of 
time, which will be provided if it is available. This operation will be continued 
until the user elects to the end the service or the balance in the prepaid system 
becomes zero. This ensures that a negative balance is not accumulated, which can 

15 be a problem with existing billing systems. Additionally, because the system uses 
amounts or "chunks" of time from tlie prepaid system, at the end of the service any 
unused amount of time is retumed to the prepaid system. The billing/refund 
operation of this aspect of the present invention can operate similar to that 
previously discussed. 

20 Additionally, in some cases the "amount" or "chunk" received from the 

prepaid system can be an amount of data. This can be used when the Voice XML 

is extracting data from some source (e.g. some web server containing text or audio 

file) that determines the charge based on the amount of data (bytes) and not the 
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time to present or transmit it. In this case, the mechanism and/or system used can 
be as explained earlier but the amount measured and exchanged will be bytes or 
service data and not tokens or money. It should be further noted that in some cases 
the two unused amounts (i.e. data and time) can be retumed to the prepaid system 
5 and the system will measure the minimum of the two options. 

Further, rather than request a chunk or amount and retum the "left over" to 
the system, the system can "reserve" an amount of service. In retum for the 
reservation request the system will receive (and reserve) the time/data to grant the 
service. When the reserved amount is complete or used up the system will request 

10 the prepaid system to "charge" the amount and reserve the next chunk. At the last 
chunk, which will usually be smaller than the allowed chunk, the system will 
request to charge the exact amount of service. For example, if the system was 
granted 60 seconds (under reserve) it will charge 45 seconds. The benefit of this 
method of system operation (as opposed to charge and credit at the end) is that if 

1 5 the system fails, the end user is never overcharged. 

Further, the Voice XML interpreter shown in Figures 4-7 can be used to 
control the length of the operation or session in conjunction with the prepaid 
system. In Figures 4 and 5, the prepaid fimctionality (the VoiceXML interpreter or 
the VoiceXML platform) refers to the Tariff engine and the prepaid system as one 

20 unit. However, in Figures 6 & 7 the requester first accesses the Tariff engine to 
convert the service related feature (time/data) to a money amount and then 
connects to the prepaid system to actually charge/credit/reserve (depending on the 
mode of operation) this amount. 
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To perform the above function a Voice XML tag which commands the 
Voice XML interpreter or platform to send a charging record, or check the system 
for sufficient funds (or time), can be added to any number of existing or required 
Voice XML tags. For example, the additional tag required for the present 
5 invention can be added to the transfer, prompt, aad/or call initiation request tags 
already existing in the Voice XML system. It is noted that the Voice XML tag for 
the present invention is not limited to these locations, but can also be placed in any 
other appropriate location. As an example, when a user requests a service from a 
web server, initially the web server cannot "talk" or communicate with the prepaid 

10 system, so within the Voice XML "prompt" tag a tag or parameter is added to 
cause the web server to get "permission" from the prepaid server, to transmit data 
for a set time period. When the Voice XML platform or interpreter receives the 
command to proceed it will proceed with the service, but at every pre-set time 
period it will inform the prepaid system of the service it is giving and will request 

1 5 permission to continue. It is noted that in the preferred embodiment, the system 
will request permission from the prepaid system to proceed before service actually 
begins. Further, in yet another embodiment of this aspect of the invention, a Voice 
XML tag can be inserted which contains a URL to which data regarding the service 
can be sent at every time period or interval in the data transfer. 

20 It is to be noted that the present invention is not limited to the use of Voice 

XML, but can be used with any scripting language that executes at the system 

platform or interpreter. 

Further, in addition to being used in voice network application, the above 
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embodiment can also be used in data transfer applications in a similar fashion. 
However, in the preferred embodiment, if the data transfer is incomplete and 
results in useless information to the wireless device 12, the billing system (i.e. 
prepaid server 34) is triggered to not bill for the connection time, as the data 
5 transfer was unsuccessful. 

Further, it is contemplated that this embodiment of the present invention can 
be coupled with any or all of the embodiments previously discussed. For example, 
before a data transfer occurs a cost for the transfer is calculated or estimated, and 
the prepaid server 34 determines whether or not sufficient "tokens" exist in the 

10 appropriate account before the data transfer is allowed to continue. When the 

prepaid server 34 determines that the transfer can continue, the above embodiment 
can be incorporated to monitor the actual coimection time, thus allowing the 
prepaid server 34 to determine whether or not the actual coimection time exceeds 
the calculated or estimated amount and interrupts the transfer or connection when 

1 5 such an event occurs. 

It should be finally noted that the above aspects of the present invention are 
not limited to prepaid billing systems, as previously described, but can be used in 
any IVR system where there is the possibility for a voice/data connection record to 
be lost when a failure occurs in the server or system handling the connection, nor is 

20 the present invention limited to wireless communication systems. 

It will be appreciated that the above descriptions are intended only to serve 
as examples, and that many other embodiments are possible within the spirit and 
the scope of the present invention. 
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1 . A method for providing prepaid data transfer service, the method 
comprising: 

(a) receiving a request for data; 

(b) calculating a cost of providing the data; and 

(c) determining whether a sufficient amount to cover said cost is 
available in an account. 

2. The method of claim 1, further comprising: 

(d) initiating the data transfer service if said sufficient amount is 
available. 

3. The method of claim 2, further comprising: 

(e) blocking the data transfer service if said sufficient amount is not 
available. 

4. The method of claim 3, further comprising: 

(f) sending a message or said data to a wireless device. 

5. The method of claim 4, wherein said message comprises a recharge 

URL. 
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6. The method of claim 1, wherein (b) is performed by calculating said 
cost according to at least one of an amount of data required for the data transfer 
service, a type of data and an identity of a data source for providing the data, the 
date and time of the data transfer, and the subscriber's class of service. 

7. The method of claim 6, wherein (b) further comprises: 

(i) calculating a cost of the data transfer service in an arbitrary unit; and 

(ii) converting said arbitrary unit into a charge to said prepaid account of 
the subscriber. 

8. The method of claim 7, wherein (ii) is performed according to at 
least one of the date and time of the data transfer, and a class of service for the 
subscriber. 

9. The method of claim 8, wherein said class of service is defined 
according to at least one rule for each subscriber. 

10. The method of claim 8, wherein (i) is performed according to at least 
one of an amount of data required for the data transfer service, a type of data and 
an identity of a data source for providing the data. 

1 1 . The method of claim 1 , wherein (b) comprises : 

(i) calculatmg a cost of the data transfer service in an arbitrary unit; and 
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converting said arbitrary unit into a charge to said prepaid account of 
the subscriber. 



12. The method of claim 1 1, wherein said arbitrary unit is set with an 
expiration thne. 



13. The method of claim 12, wherein after said expiration time said 
arbitrary units are converted into a second charge to said prepaid account, wherein 
said second charge has a different value than said charge. 

14. The method of claim 12, wherein said expiration time is a function of 
at least one of the date and time. 

15. The method of claim 1, wherein a sufficient amount is determined as 
an amount in said prepaid account above a minimum negative balance threshold. 

16. The method of claim 1, further comprising: 

(d) calculating an actual cost for performing the data transfer service; 

and 

(e) obtaining payment from said prepaid account of the subscriber. 



17. The method of claim 16, wherein (d) is performed only after the data 
transfer service is complete. 
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18. The method of claim 16, wherem (d) is perfomied as the data transfer 
service is being performed. 

19. The method of claim 1, further comprising: 

(d) transmitting said data; and 

(e) monitoring an actual cost of transmitting said data. 

20. The method of claim 19, wherein said monitoring occurs at a set 
interval during transmitting of said data. 

2 1 . The method of claim 19, further comprising: 

(f) blocking said the data transfer if said actual cost exceeds said 
calculated cost. 

22. The method of claim 1, further comprising: 

(d) denying a service user, having a class of service, from receiving said 
data if said sufficient amount is not available, wherein said denial is based on at 
least said user's class of service, 

23 . A method of providmg a prepaid data transfer service, the method 

comprising: 

(a) receiving a request for data; 
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(b) estimating a cost of providing said data; 

(c) determining whether a sufficient amount to cover said estimated cost 
is available in an. account; 

(d) initiating the data transfer service if said sufficient amount is 
available; and 

(e) monitoring an actual cost of the data transfer service during the data 
transfer service. 

24. The method of claim 23, wherein said monitoring occurs at a set 
interval during said data transfer service. 



25. The method of claim 23, further comprising: 

(f) blocking the data transfer service is said actual cost exceeds the 
estimated cost. 

26. A system for providing a prepaid data transfer service to a subscriber 
of data from a data source, comprising: 

(a) a comimimication device for operation by the subscriber; 

(b) a data network for connecting said communication device to the data 
source; and 

(c) a prepaid system for being connected to said data network and said 

communication device, for determining a cost for transferring the 

data to said communication device and for storing a subscriber 
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account, said subscriber account having a prepaid amount, such that 
said prepaid system determines whether to permit the data transfer 
service according to a comparison of said cost and said prepaid 
amount in said subscriber account. 



27. The system of claim 26, wherein said prepaid system comprises: 

(i) a data monitor connected to said data network for monitoring data 
traffic over said data network, including a request from said 
communication device for the data transfer service, and for 
calculating said cost; and 

(ii) a prepaid server for managing said subscriber account and for 
determining whether to authorize the data transfer service according 
to said comparison between said cost and said prepaid amount. 



28. The system of claim 11, wherein said data monitor calculates said 
cost in arbitrary units, and said prepaid server converts said arbitrary units into an 
actual amount for debiting said subscriber account. 

29. The system of claim 28, wherein said arbitrary units are set with an 
expiration time. 

30. The system of claim 29, wherein after said expiration time said 

prepaid server converts said arbitrary units into a second actual amount for debiting 
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said subscriber account, wherein said second actual amount is different than said 
actual amount. 



3 1 . The system of claim 29, wherein said expiration time is a function of 
at least one of the date and time. 

32. The system of claim 26, further comprising: 

(d) a voice network in communication with said prepaid server, such that 
said prepaid server also determines whether to authorize a voice 
service according to a comparison between a cost of said voice 
service and said prepaid amount. 

33. The system of claim 26, wherein said prepaid system monitors a 
connection between said communication device and said data source 
at a preset interval and determines an actual cost of said connection 
during said connection at each occurrence of said interval, such that 
said prepaid system determines whether to permit the data transfer 
service according to a comparison of said actual cost and said prepaid 
amount in said subscriber account. 

34. The system of claim 32, wherein said prepaid system monitors a 

connection between said communication device and at least a second 

wireless device connected to said voice network at a preset interval 
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and determines an actual cost of said connection during said 
connection at each occurrence of said interval, such that said prepaid 
system determines whether to continue said connection between said 
commimication device and said second communication device 
according to a comparison of said actual cost and said prepaid 
amount in said subscriber account. 

35. The system of claim 26, wherein said communication device is a 
wireless communication device. 



36. The system of claim 26, wherein said communication device is a 
wireline communication device. 

37. A system for providing a prepaid data transfer service to a subscriber 
of data from a data source, comprising: 

a prepaid system, wherein said prepaid system determines a cost for 
transferring data and stores a subscriber account, said subscriber account having a 
prepaid amount, such that said prepaid system determines whether to permit the 
data transfer service according to a comparison of said cost and said prepaid ^ 
amount in said subscriber account. 

38. The system of claim 37, further comprising a communication device 

for operation by said subscriber. 
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The system of claim 37, further comprising a data network for 
connecting a communicating device to the data source. 
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Title: MANAGEMENT OF PRE-PAID BILLING SYSTEM FOR 

5 WIRELESS COMMUNICATION 



FIELD AND BACKGROUND OF THE INVENTION 

The present invention is of a method and a system for management of pre- 
paid billing for commxmication systems, and in particular, of such a system and 
10 method for real time pre-paid billing for data transfer in the wireless and wireline 
communication environment. The present application claims priority under 35 
U.S.C. § 1 19 based on U.S. Provisional Application 60/267,413 filed on February 
9,2001. 

Cellular telephones are becoming increasingly popular for portable 
15 telephone use, particularly for users who are interested in rapid, mobile data 

communication. As the amount of computational power and memory space which 
are available in such small, portable electronic devices increases, demand arises for 
different types of communication services through such devices. In particular, 
users have demanded that cellular telephones receive many different types of 
20 multimedia data, including e-mail (electronic mail) messages and Web pages. 

In response to such demands, and to extend the power and efficacy of 
operation of portable, wireless electronic communication devices, the WAP 
(wireless application protocol) standard has been developed. Another such data 
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transfer standard is known as "i-Mode", which is currently used in Japan for data 
transfers, but which is also now being considered for operation in Europe and other 
countries. These data transfer standards enable the subscriber to access the Internet 
through the wireless communication device. In addition, various messaging 
5 standards such as SMS (short messaging service) also exist, and can be used to 
transfer text based messages between wkeless commimication devices. 

All of these different types of wireless data services are currently provided 
to data-enabled wireless telephones by servers or gateways. Typically, these 
servers or gateways are connected to a wireless telephone network on one side and 

10 to some other network ("external network"), such as the Intemet, on the other side. 
For example, an SMSC receives a text message from the Internet or other source 
and sends one or more data packets over a wireless telephone network to a 
particular wireless telephone, which then displays the text message on the wireless 
telephone's display screen. In another example, an HDML or WAP gateway 

15 receives a request generated by a micro-browser in the wireless telephone and 
sends a corresponding request to a server on the Internet. The Internet server 
responds with data, typically formatted according to a markup language, such as 
HDML or WML, and the gateway forwards this data to the micro-browser for 
display on the wireless telephone's screen. Alternatively, the gateway reformats 

20 the data according to a different standard data format before sending the data to the 
wireless telephone. 

Regardless of the particular data transfer standard which is used, a basic 
requirement for effectively operating such services is the ability to appropriately 
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bill the subscriber for these types of services. The current specifications and 
implementations of wireless data network elements do not allow for real-time data 
billing. The actual need may vary, depending on the types of services being offered 
and the role of the operator in offering such services, but the need for a real-time 

5 prepaid data billing solution is evident. 

One example of a system in which such a pre-paid data service billing 
solution would be useful is the GPRS (general packet radio service) system, as 
shown in background art Figure 1. The GPRS architecture features a system 10 
which contains a wireless device 12, which may be a cellular telephone for 

10 example. Wireless device 12 is connected to a base station 14, which contains a 
BSC (base station controller) 16. BSC 16 is in turn in communication with a 
SGSN (serving GPRS support node) 18. SGSN 18 is a network element which is 
responsible for supporting data communication between wireless device 12 
(through BSC 16) and an internal GPRS packet network 20, including packet 

15 routing and transfer, mobility management, logical linlc management, and 
authentication and charging Amotions 

Internal GPRS packet network 20 is in turn in communication with a GGSN 
(gateway GPRS support node) 22, which for the purposes of this explanation is an 
example of one implementation of a data gateway, connecting an internal data 

20 network (internal GPRS packet network 20) to an external network, such as the 

Internet 24. GGSN 22 connects GPRS packet network 20 to the Internet 24. 

GGSN 22 communicates with devices coimected to the Internet 24 (not shown) 

through such protocols as Radius, and effectively acts as an IP routing platform. 

3 
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GGSN 22 also converts the GPRS packets received from SGSN 18 into the 
appropriate packet data protocol format, such as IP or X.25 for example, as well as 
re-addressing packets received from Intemet 24 into the correct address of wireless 
device 12, typically the correct GSM address. 
5 Although background art system 10 operates effectively for the purpose for 

which it was designed, namely the transfer of data between the Intemet 24 and 
wireless device 12, background art system 10 unfortunately has a number of 
drawbacks with regard to billing. As previously described, the network elements of 
background art system 10, such as GGSN 22 and SGSN 18, currently cannot 
1 0 support billing activities . 

There is, therefore, a need for a system for billing for wneless data 
communications that both enables individuals without sufficient credit to engage in 
this type of communication and ensures all data communications are paid for, 
without extendmg credit to these individuals. 

15 

SUMMARY OF THE INVENTION 

The present invention is a system and method for providing prepaid data 
transfer services to a subscriber through a wireless device. The wireless device is 
connected to a data network for transferring data from a data source, such as the 
20 Internet, for example. A prepaid system monitors the data network in order to 

determine whether a particular requested data transfer service should be authorized, 
for example according to the amount available in the account of the subscriber. It 
should be noted that the description of the present invention is discussed in terms 
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of a wireless communication system, however, the present invention can be equally 
applied to wireline communication systems with existing, known wireline 
technologies, without altering the scope of the present invention. 

In one embodiment of the invention, the flow of operations is described as 
5 follows. Firsts the subscriber prepays for service, which can be accomphshed 
according to any one of a number of different mechanisms which are known in the 
background art. Next, the subscriber uses a wireless device, such as a cellular 
telephone for example, to access data services, such as SMS or the Internet. The 
request for access is intercepted by the prepaid billing system of the present 

10 invention, which is preferably connected between the extemal network and a 

GGSN, or other gateway, which resides between the extemal network (such as the 
Internet) and the internal data network (such as an internal GPRS packet network). 
The prepaid system thereby intercepts data traffic which would otherwise travel 
directly between the extemal network and the internal data network, as well as 

15 between the wireless device and the external network. 

The prepaid system preferably then determines how the data traffic should 
be handled. For example, the prepaid system could optionally selectively allow the 
data traffic to flow, or altematively could discard the traffic, depending on the 
remaining account balance of the subscriber and, optionally, the nature of the 

20 traffic. The prepaid system preferably examines packets representing requests or 
data flowing firom, or to, the wireless device and debits the prepaid account balance 
for the subscriber. According to preferred embodiments of the present invention, 
the calculation of the debit is divided into two parts. Accordmg to a fnst part, the 
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component of the prepaid system which actually receives the request from the user 
calculates the debit in terms of "tokens", which are arbitrary internal units for 
charging for data transfer. Next^ in the second part of the calculation process, the 
value of the tokens is converted to a monetary value for debiting the account of Ihe 
5 user, optionally according to particular characteristics of the user. Thus, the 

component of the prepaid system according to the present invention which receives 
the request, such as the data monitor, may optionally not receive any information 
about the user, but only sufficient tokens for the data transfer process to occur. 
Preferably, however, the class of service mformation is received. 

10 The amount of the debit can depend on the size of the packet or the number 

of packets, for example the account can be debited for each "n" bytes or for each 
page to be displayed. Optionally, the amount of the debit could depend on the type 
of request or data in the packet. For example, request packets might optionally be 
free. Music data might optionally be charged at a lower rate than other kinds of 

15 data packets. Packets with error messages might be free. The amount debited 

might depend on the URL of the destination of the request or the source of the data 
being returned. Some URLs could optionally and preferably be "sponsored", in 
that the owner of the server that handles that URL pays part or all of the cost of 
requests and/or data sent to/from the server. 

20 Optionally, the amount of debit depends upon the date and time of the data 

transfer, and the location of the mobile device at the time of transfer, as well as the 

subscriber's class of service (CoS). 

The prepaid system preferably allows packets to be transferred between the 

6 
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wireless device and the data service provider (server) only if the subscriber's 
account balance is sufficient and/or if the packets are "free". Optionally and more 
preferably, the system notifies the subscriber when the subscriber's balance is low 
or exhausted, for example via an SMS message or an HDML message sent to the 
5 wireless device. Alternatively, the prepaid system can optionally notify the 
subscriber by sending a message containing a pointer (for example a "recharge 
URL") to a page that contains such a message. 

Hereinafter, the term "wireless device" refers to any type of electronic 
device which permits data transmission and/or reception through a wireless 

10 channel, for example through transmission and/or reception of radio waves. 
Hereinafter, the term "cellular telephone" is a wireless device designed for the 
transmission of voice data and/or other data. Non-limiting examples of such data 
include text data, graphical data, audio data, video data, and "documents" 
described in a "mark-up" language. 

15 Hereinafter, the term "computational device" includes, but is not limited to, 

any type of wireless device and any type of computer. Examples of wireless 
devices include, but are not limited to, handheld devices, including devices 
operatmg with the Palm OS®; hand-held computers, PDA (personal data assistant) 
devices, cellular telephones, any type of WAP (wireless application protocol) 

20 enabled device, and wearable computers of any sort, which can be connected to a 
network as previously defmed and which have an operating system. 

The present invention could be implemented in software, firmware or 
hardware. The present invention could be implemented as substantially any type of 
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integrated circuit or other electronic device capable of performing the functions 
described herein. 

In any case, the present invention can be described as a plurality of 
instructions being executed by a data processor, in which the data processor is 
5 understood to be implemented according to whether the present invention is 
implemented as software, hardware or firmware. 



BRIEF DESCRIPTION OF THE DRAWINGS 

The invention is herein described, by way of example only, with reference 
10 to the accompanying drawings, wherein: 

FIG. 1 is a schematic block diagram showing a background system; 

FIG. 2 is a schematic block diagram showing a system accordmg to the 
present invention for pre-paid billing of data services; 

FIG. 3 is a schematic block diagram of a system for voice and data 
1 5 integration according to the present invention; 

FIG. 4 is a schematic block diagram of an exemplary system for voice and 
data transfer according to the present invention; 

FIG. 5 is a schematic block diagram of an alternate exemplary system for 
voice and data transfer according to the present invention; 
20 FIG. 6 is a schematic block diagram of an additional alternate exemplary 

system for voice and data transfer according to the present invention; and 

FIG. 7 is a schematic block diagram of another alternate exemplary system 

for voice and data transfer according to the present invention. 

8 
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DESCRIPTION OF THE PREFERRED EMBODIMENTS 

The present invention will be explained in further detail by making 
reference to the accompanying drawings, which do not limit the scope of the 
5 invention in any way. Again, it should be noted that the application of the present 
invention is not limited to wireless communication systems, but can also be applied 
in wireline communication systems, using existing and known technologies in a 
similar fashion to that disclosed below. 

The present invention is of a system and method for providing prepaid data 

10 transfer services to a subscriber through a wireless device. The wireless device is 
connected to a data network for transferring data from, or to, a data source, such as 
the Intemet. A prepaid system monitors the data network in order to determine . 
whether a particular requested data transfer service should be authorized, for 
example, according to the amount available in the account of the subscriber, 

15 In one embodiment, the flow of operations is described as follows. First, the 

subscriber prepays for service, which can be accomplished according to any one of 
a number of different mechanisms which are known in the background art. Next, 
the subscriber uses a wireless device, such as a cellular telephone for example, to 
access data services, such as SMS or the Intemet. The request for access is 

20 intercepted by the prepaid billing system of the present invention, which is 

preferably connected between the external network (for example the Intemet 24) 

and GGSN 22, or other gateway which resides between the external network and 

the internal data network (such as an intemal GPRS packet network 20). The 

9 
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prepaid system thereby intercepts data traffic which would otherwise travel directly 
between the external network and the internal data network, as well as between the 
wireless device and the external network. 

The prepaid system preferably then determines how the data traffic should 
5 be handled. For example, the prepaid system could optionally selectively allow the 
data traffic to flow, or altematively could discard the traffic, depending on the 
remaining account balance of the subscriber and, optionally, the nature of the 
traffic. The prepaid system preferably examines packets representing requests or 
data flowing firom, or to, the wireless device and debits the prepaid account balance 

10 for the subscriber. According to preferred embodiments of the present invention, 
the calculation of the debit is divided into two parts. In the first part, the 
component of the prepaid system which actually receives the request fi"om the user 
calculates the debit in terms of 'tokens", which are arbitrary intemal units for 
charging for data transfer. It is noted that although the present discussion involves 

15 a server controlling the billing process, it is also contemplated that the wireless 
device can used and programmed to control or manage the prepaid billing as 
described herein. 

Next, in the second part of the calculation process, the value of the "tokens" 

is converted to a monetary value for debiting the account of the user, optionally 

20 according to particular characteristics of the user. Thus, the component of the 

prepaid system according to the present invention which receives the request, such 

as the data monitor, may optionally not receive any information about the user, but 

only sufficient tokens for the data transfer process to occur. Preferably, however, 

10 
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the class of service information is received. 

The way in which the debit is calculated can vary, and the amount of the 
debit can depend on the size of the packet or the number of packets. For example, 
the account can be debited for each "n" bytes or for each page to be displayed, 
5 Optionally, the amount of the debit can depend on the type of request or data in the 
packet. For example, request packets might optionally be free. Music data might 
optionally be charged at a lower rate than other kinds of data packets. Packets with 
error messages might be free. The amount debited might depend on the URL of 
the destination of the request or the source of the data being retumed. Some URLs 
10 could optionally and preferably be "sponsored", in that the owner of the sei-ver that 
handles that URL pays part or all of the cost of requests and/or data sent to/from 
the server. 

Additionally, the amount of debit could depend upon the date and time of 
the data transfer, and/or the location of the mobile device at the time of transfer, as 

15 well as the subscriber's class of service (CoS). 

The prepaid system preferably allows packets to be transferred between the 
wireless device and the data service provider (server) only if the subscriber's 
account balance is sufficient and/or if the packets are "free". Optionally and more 
preferably, the system notifies the subscriber when the subscriber's balance is low 

20 or exhausted, for example via an SMS message or an HDML message sent to the 

wireless device. Altematively, the prepaid system can optionally notify the 

subscriber by sending a message containing a pointer (for example a "recharge 

URL") to a page that contains such a message. 

11 
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The principles and operation of a method and a system according to the 
present invention may be better understood with reference to the drawings and the 
accompanying description. It is understood that although the present invention is 
described with regard to GPRS, this is for the purposes of description only and is 
5 without any intention of being limiting, as the present invention would also 

optionally be operative with other data networks, such as CDMA, WCDMA (SG), 
iDen and even Circuit Switched Data, and any other known or used data network. 
Since data monitoring is done between the intemal Packet Data Network and the 
Intemet (or another extemal network), the product can work with any such intemal 

1 0 Packet Data Network. 

Referring now to the drawings, Figure 2 shows an exemplary 
implementation of a system 30 according to the present invention. System 30 
features a number of the same elements as system 10 of background art Figure 1 ; 
unless otherwise noted, identically numbered elements have at least the 

1 5 functionality described with regard to Figure 1 . 

System 30 differs from background art system 10 in that system 30 also 
features a data payment server 32, a data monitor 38 and a prepaid server 34. As 
described in greater detail with regard to Figure 3 below, optionally and preferably, 
prepaid server 34 is also in communication with a voice network 36. Data payment 

20 server 32, however, is more preferably only in communication with the data 
transfer elements of system 30. Data payment server 32 is an optional but 
preferred component of system 30 for management of the prepaid system and for 
handling protocols. 

12 



wo 02/067600 PCT/US02/01243 

As shown, prepaid server 34 communicates with data monitor 38 
(optionally through Data Payment Server 32) in order to be able to determine the 
type of data transfer services which are being provided from Internet 24 and/or 
another external network. Data monitor 38 monitors all data traffic from Internet 
5 24 and/or another external network, and reports on a number of characteristics of 
such traffic to prepaid server 34. Such characteristics include, but are not limited 
to, the type of data being transferred and/or the type of data which is requested to 
be transferred, the amount of data being transferred and the identity of the 
subscriber (or wireless device 12) for which the data is being transferred. For 

10 example, request packets might optionally be free. Music data might optionally be 
charged at a lower rate than other kinds of data packets. Packets with error 
messages might be free. Thus, data monitor 38 more preferably calculates the 
charge for the data transfer according to an arbitrary internal unit, which is 
described in greater detail below as a "token", which most preferably does not 

15 require any information about one or more characteristics of the subscriber. 

Prepaid server 34, data payment server 32 and data monitor 38 may 
collectively be termed a "prepaid system", and optionally may also include a DPS 
manager 39 (see below for a description). 

Prepaid server 34 preferably receives the number of tokens, or other 

20 information, from data monitor 38 (optionally through Data Payment Server 32), 

and then calculates the amount of payment which is required for the data transfer to 

occur, more preferably according to at least some of the above characteristics. This 

amount of payment is preferably calculated in terms of actual money to be charged 

13 
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to the account of the subscriber and, therefore, preferably represents a conversion 
from the arbitrary tokens of data monitor 38. 

Optionally, payment could also be calculated according to the date and time 
of day for the transfer. The amount debited might also optionally depend on the 
5 service provider for the data transfer service, such as according to the URL of the 
destination of the request or the source of the data being retumed. Some URLs or 
other specific data sources could optionally and preferably be "sponsored", in that 
the owner of the server that handles that URL pays part or all of the cost of 
requests and/or data sent to/from the server (not shown). 

10 According to one embodiment of the present invention, the charging of 

subscribers can be based on, or controlled by, the amount of data being transferred 
(which can optionally and preferably include different basic billing blocks, such as 
bytes, kilobytes, images, songs, documents, programs and so forth). Additionally, 
different rates for uplink and downlink can be used. Also, for content-based 

15 billing, differential billing according to such data characteristics as the content type 
of the data (such as WAP or HTTP for example), data protocol (WAP, HTTP, FTP, 
TELNET, P0P3, and so forth) and location of the data source (such as the URL for 
WAP and HTTP transfers), can be used, alone or in combination. 

Other preferred features include the ability to determine rates according to 

20 the time of day, the date or other time-based rate information. Service is also 

optionally and more preferably determined according to access control rules for 

different classes of service, which are in turn determined according to one or more 

characteristics of the subscribers. Different subscribers might, therefore, be 

14 
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charged different amounts for the same data, according to their class of service. 
Additionally, special rules axe also optionally and more preferably determined for 
secured protocol transfer. 

Further, one optional but particularly preferred feature, of the present 
5 invention, is that data monitor 38 calculates the total amount required for the data 
transfer to occur before such a transfer actually occurs, at the stage when the 
subscriber is sendmg the request for the data transfer. If such a calculation is 
performed in terms of an arbitrary internal unit such as tokens, then preferably a 
sufficient niraiber of such tokens or other units are received from prepaid server 34, 

10 which then debits the account of the subscriber accordingly. This procedure 

predicts the cost of the transmission and ensures that the subscriber's account can 
afford this predicted cost. Optionally and more preferably, data monitor 38, 
preferably in conjunction with prepaid server 34 (optionally through Data Payment 
Server 32), also calculates the actual amount required for the data transfer as it 

1 5 actually occurred, since the transfer may not be successful if the connection to the 
data source and/or to v^reless device 12 is lost, for example, in which case less 
data is sent than predicted. In other cases, more data is sent than predicted. 

In any case, data monitor 38 sends the required number of tokens to be 
obtained from the account of the subscriber to prepaid server 34 (optionally 

20 through Data Payment Server 32), if data monitor 38 does not have sufficient 

tokens for that particular subscriber. Prepaid server 34 then determines whether the 

account of the subscriber has sufficient funds to cover the requested number of 

tokens. If sufficient funds are available, then prepaid server 34 sends the requked 

15 



wo 02/067600 PCT/US02/01243 

tokens to data monitor 38, thereby enabling the transfer to occur, and debits the 
account of the subscriber appropriately. Alternatively, if sufficient funds are not 
available, then prepaid server 34 sends a message to data monitor 38 to block the 
transfer, and does not send the tokens. Such a message is then optionally and more 
5 preferably also sent to the subscriber through wireless device 12. 

Optionally and more preferably, the subscriber is notified of changes in 
balance and account status while wireless device 12 is engaged m a data transfer. 
Most preferably, the subscriber is notified that access denial is about to occur 
during the data transfer, if the remaining amount in the account of the subscriber is 

10 not sufficient to complete the data transfer. For example, if data monitor 38 
requires tokens for the transfer, but is informed by prepaid server 34 (optionally 
through Data Payment Server 32) that no more tokens can be obtained, then 
preferably this imminent access denial is communicated to the subscriber. 
According to other preferred embodiments of the present invention, the subscriber 

15 is allowed to have a negative amount in the user account, smiilar to an overdraft at 
a bank, for example in order to permit a data transfer operation to be completed 
even after the prepaid subscriber account has been depleted of fimds. Such a 
negative amount may optionally be Umited according to a 'threshold of denial", 
below which the subscriber is denied fiirther service until money is again 

20 transferred into the account. 

Also optionally. Call Detail Records (CDRs) are created for data transfers 

for prepaid subscribers. CDRs are records generated and stored in the prepaid 

system. These records provide an audit of charges applied to a subscriber's 

16 
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account. In support of data transfers, these records minimally contain the 
subscriber ID, time, date, charge amount, and type (data transfer) for each charge 
applied. 

According to an exemplary but preferred implementation of the present 

5 invention, each prepaid subscriber receives services according to a specific class of 

a number of different classes, which are defined by the operator. For each class of 

service there are one or more rules, or parameters. 

The parameters for each class of service optionally and more preferably 

include, but are not limited to, the type of service according to various data sources 

10 (identified for example by the destination URL, IP Address or other means), such 

as news, banks and/or other financial institutions for management of financial 

account(s) of the subscriber, games and so forth; the type of protocol which is 

required to deliver the service such as HTTP, FTP, WAP and so forth; the direction 

of data transfer for uplink vs. downlink; the content type such as text, image, 

15 animation, video, audio and so forth; and access permission to any particular type 

of service, defined as permit or deny. The operator is then preferably responsible 

for defining the priority between the different rules of the same class of service. 

One example of such a set of rules is shown in the table below. As shown, 

each rule pertains to a particular class of service (CoS), and may also be 

20 determined according to any one or more of the following characteristics of the 

data transfer: a particular service within the class ("service")^ a particular protocol 

for the data ("protocol"), the direction of data transfer ("up/down")^ the type of 

content ("content type")^ the status (return code of the application level protocol, 

17 
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such as HTTP "status" return flag), whether access permission is permitted or 
denied, and the weight. The weight is the number of tokens that should be charged 
for every basic billing block of data that matches the specified transfer rules (such 
as Protocol, Content, Status and so forth). The weight is a real number, and is more 
5 preferably permitted to be a fraction, as well as positive, zero or negative. 
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Data monitor 38 is preferably responsible for finding the exact rule which 



matches the data being monitored, and then to calculate a charge for the data 
1 0 transfer. More preferably, the charge is calculated according to a number of tokens 

to be paid for this data transfer. The calculation is optionally performed according 

to the following equation: 

#Tokens = Weight * Basic Billing Block 

in which the basic billing block is a parameter which is configured by the operator, 
15 and the weight is the amount of such billing blocks which is required to pay for 

each such data transfer service. Each token is thus a basic unit for charging the 

subscriber. Prepaid server 34 determines how much money is available to the 
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subscriber. Data monitor 38 calculates the number of tokens required for each 
transaction and then requests more tokens from prepaid server 34 as necessary 
(optionally through Data Payment Server 32). If sufficient tokens are available, 
then data monitor 38 enables the data transfer to occur. 
5 Prepaid server 34 is, therefore, also responsible for translating the money 

received from the subscriber into tokens, optionally and more preferably according 
to the date, time, location of the mobile station at the time of transfer and 
subscriber's Class of Service. In order to assist conamunication between data 
monitor 38 and prepaid server 34 (optionally through Data Payment Server 32), a 

1 0 Token Request and Refund Message is more preferably provided. This message is 
preferably used by data monitor 38 to interact with prepaid server 34 for subscriber 
authentication and token transfers. This message is optionally divided into several 
parts. A first part is the "request tokens" part, which is used to request subscriber 
configuration information and debit a subscriber's account. A "refund tokens" part 

1 5 is preferably used to refund unused tokens. Both parts can optionally be combined 
in one message. 

The message is optionally used in four different situations. First, when tlie 

subscriber is trying to connect to the data transfer service, the message is used to 

check whether the subscriber is a prepaid user and an initial "chunk" of tokens is 

20 sent to data monitor 38 for the subscriber's use. Next, if the subscriber's credit at 

data monitor 38 is zero, and more tokens are required to continue data transfer, the 

message is also preferably sent in order to receive more tokens. In addition, the 

message is used when the previously transmitted tokens have expired, in which 
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case they are refunded and new (fresh) tokens are requested, or when the user 
disconnects. The expiration of tokens occurs at any interval, or at any set time, 
desired by the system operator. Expiration is used to value tokens differently for 
different times of use. For example, on weekends and hoUdays tokens can be 
5 valued at 40 tokens for $1.00, whereas nights can be valued at 30 tokens for $1 .00 
and daytime/weekday tokens can be valued at 20 tokens for $1 .00. In the preferred 
embodiment, the prepaid server 34 sends the tokens to the data monitor 38 
(optionally through Data Payment Server 32) with expiration times, so that the data 
monitor 38 send the tokens back to the prepaid server 34 when they expure to 
10 exchange them for "new" tokens reflecting the new value. 

Optionally and most preferably, a DPS manager 39 is provided for 
managing the functions of data payment server 32, data monitor 38 and/or prepaid 
server 34. 

Figure 3 is a schematic block diagram of another preferred embodiment of 
15 the present invention, in which prepaid server 34 handles prepaid services for both 
a voice network 36 and a data network 40. Data network 40 is shown as being 
connected to both the Internet 24 and data monitor 38. In this preferred 
embodiment, prepaid server 34 distributes tokens to both data monitor 38 and voice 
network 36, such that both types of services can optionally be operated on a 
20 prepaid basis. 

In yet another embodiment of the present invention, a slightly different 
billing system is used, particularly when a voice call is being handled by the voice 
network 36. In this embodiment, in addition to the prepaid server 34 handling the 
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prepaid service, the prepaid server 34 monitors the connection of the wireless 
device 12 in the voice network 36, and sends a billing or time record of the 
connection at a set interval during the connection. For example, the interval could 
be set to send the connection data every one minute. 

5 This embodiment is particularly useful when, in a voice network 36, there is 

a long connection of voice or data transmission, where it is difficult orimpossible 
to determine a proper prepaid amount at the beginning of the connection. In 
current data transmission and voice network systems, if the server handling the 
connection to the vsrireless device 12 fails before a proper connection hang-up or 

10 disconnect is received, the bilhng data for the call or data transfer is lost. This 
results in a significant amount of connection time being lost and not billed to the 
user. The present embodiment avoids this problem by monitoring the connection 
at a preset interval during the connection and making a record of the connection at 
every occurrence of tiie interval. 

15 The prepaid server 34 (or any appropriate system platform which is not 

handling the actual connection) monitors and stores the connection or data transfer 
information dimng the coimection at tiie set interval and continually updates the 
comiection records at each occurrence of the preset interval. Therefore, at any one 
given time, if the coimection server or system fails before the coimection is 

20 properly terminated then only one interval of billing time will be lost. For 

example, if the coimection is monitored at one minute intervals and the coimection 

is lost at 25 minutes and 52 seconds into the connection, the system will have 

record of at least 25 minutes of connection time, which can be properly billed, 
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whereas in the prior art the entire connection time is lost and remains un-billed. 

The interval to be used can be set at any time or duration depending on the 
system capabilities and billing requii*ements of the system operator. For example, 
the connection can be monitored at intervals of 10 seconds, however, this creates a 

5 significant amount of data to be collected and stored during a connection and can 
create a significant burden on some systems (depending on the system capacity). 
This is to be balanced with the billing requnements that are desired. For example, 
if the billing requirements are not as critical (i.e. the time used is not as costly), 
then an interval of one minute, or longer, may be used. 

10 In a preferred embodiment of this aspect of the invention, a code "tag" is 

added to the Extensible Markup Language (XML) that is used to allow the 
commimication of the wireless device 12 to the data network 40 or voice network 
36. (Although it is noted that the present invention is not limited to the use of 
XML and can be used with any commonly known or used wireless markup 

15 language to define the use of the data received by the wireless device 12.) The 
"tag" or added code triggers the sending of the billing records of a call or 
connection to a URL, prepaid server 34, or any other location where the 
information is needed for billing, at set intervals to allow proper billing if the 
connection is lost prior to its proper disconnect. 

20 The use of the present invention will now be discussed with regard to 

exemplary embodiments of a Voice XML system as shown m Figures 4, 5 and 6. 

As shown in these Figures a Voice XML interpreter obtains Voice XML pages 

from any one of web server 1, web server 2, or web server 3. The Voice XML 
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document which is obtained contains a script that is to be interpreted by the Voice 
XML interpreter which results in controlling the Voice XML platform. The Voice 
XML interpreter is connected to the telephony (or communication) subsystem that 
performs speech recognition, play prompt, or any other command required by the 
5 Voice XML interpreter. This results in a user interface session for a telephone, or 
communication subsystem. It is noted that the Voice XML platform and the Voice 
XML interpreter can be a part of the same unit as shown in Figures 5 and 6. The 
firewall is used in the system for security and essentially creates three zones within 
the system. There is a secured zone, protected by the firewall, a "demilitarized" 

10 (DMZ) or neutral zone, partially protected by the firewall, and the internet. It is 
noted that the DMZ, or neutral zone, is generally located between a private 
network (behind a fn^ewall) and the intemet to allow users of the intemet to access 
one or at least some of a web provider's servers, while keeping some of the private 
servers off-limits behind a firewall. The web server firom which the information, or 

15 web page, is to be obtained (i.e. web servers 1, 2 or 3) can be located in anyone of 
the three zones, as shown in Figures 4-6. When presenting information services, 
either the Voice XML interpreter or Voice XML platform can access a web server 
(1-3), file server, or any other source of data to get the requested or needed data. 
In the present invention, the Voice XML platform (or equivalent platform) 

20 will, according to its configuration, be able to determine, or would know, which 
operations or data requests require billing and those that would not. The 
configuration can also indicate that a Tariff engine should be "consulted" for every 
operation and the returned answer fi-om the prepaid system will detemiine whether 



wo 02/067600 PCT/US02/01243 

to, and how much to bill. Essentially, when the Tariff engine is "consulted" the 
system sends a query to a pre-determined address according to a pre-set of rules 
and receives instructions on how to proceed. This can be alternatively referred to 
as a "manual" mode as the system does not automatically calculate the cost, but 
5 waits for instruction. For each operation which requires billing the system will 
access the prepaid system (which can be coniBgured and operate as the prepaid 
server 34 shown in Figure 2 and previously discussed) via the Tariff engine, and 
will request a certain amount of time to give the requested service. It is determined 
whether or not such time is available, and then if the time is available the operation 

10 proceeds. When the duration of the of the requested amount of time is near its end 
(about to elapse) the Voice XML platform will ask for an additional amount of 
time, which will be provided if it is available. This operation will be continued 
until the user elects to the end the service or the balance in the prepaid system 
becomes zero. This ensures that a negative balance is not accumulated, which can 

15 be a problem with existing billing systems. Additionally, because the system uses 
amounts or "chunks" of time from the prepaid system, at the end of the service any 
unused amount of time is returned to the prepaid system. The billing/refund 
operation of this aspect of the present invention can operate similar to that 
previously discussed. 

20 Additionally, in some cases the "amount" or "chunk" received from the 

prepaid system can be an amount of data. This can be used when the Voice XML 

is extracting data from some source (e.g. some web server containing text or audio 

file) that determines the charge based on the amount of data (bytes) and not the 
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time to present or transmit it. In this case, the mechanism and/or system used can 
be as explained earlier but the amount measured and exchanged will be bytes or 
service data and not tokens or money. It should be fiirther noted that in some cases 
the two unused amounts (i.e. data £uid time) can be returned to the prepaid system 

5 and the system will measure tlie minimum of the two options. 

Further, rather than request a chunk or amount and return the "left over" to 
the system, the system can "reserve" an amount of service. In return for the 
reservation request the system will receive (and reserve) the time/data to grant the 
service. When tiie reserved amount is complete or used up the system will request 

10 the prepaid system to "charge" the amount and reserve the next chunk. At the last 
chunk, which will usually be smaller than tiie allowed chunk, the system will 
request to charge the exact amount of service. For example, if the system was 
granted 60 seconds (under reserve) it will charge 45 seconds. The benefit of this 
method of system operation (as opposed to charge and credit at the end) is that if 

15 the system fails, the end user is never overcharged. 

Further, the Voice XML interpreter shown in Figures 4-7 can be used to 
control the length of the operation or session in conjunction witti the prepaid 
system. In Figures 4 and 5, the prepaid functionality (the VoiceXML interpreter or 
the VoiceXML platform) refers to the Tariff engine and the prepaid system as one 

20 unit. However, in Figures 6 & 7 the requester fu:st accesses the Tariff engine to 
convert the service related feature (time/data) to a money amount and then 
connects to the prepaid system to actually charge/credit/reserve (depending on the 
mode of operation) this amount. 
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To perform the above function a Voice XML tag which commands the 
Voice XML interpreter or platform to send a charging record, or check the system 
for sufficient funds (or time), can be added to any number of existing or required 
Voice XML tags. For example, the additional tag required for the present 
5 invention can be added to the transfer, prompt, and/or call initiation request tags 
aheady existing in the Voice XML system. It is noted that the Voice XML tag for 
the present invention is not limited to these locations, but can also be placed in any 
other appropriate location. As an example, when a user requests a service from a 
web server, initially the web server cannot '*talk" or communicate with the prepaid 

10 system, so within the Voice XML "prompt" tag a tag or parameter is added to 
cause the web server to get "permission" from the prepaid server, to transmit data 
for a set time period. When the Voice XML platform or interpreter receives the 
command to proceed it will proceed with the service, but at every pre-set time 
period it will inform the prepaid system of the service it is giving and will request 

1 5 permission to continue. It is noted that in the preferred embodiment, the system 
will request permission from the prepaid system to proceed before service actually 
begins. Further, in yet another embodiment of this aspect of the invention, a Voice 
XML tag can be inserted which contains a URL to which data regarding the service 
can be sent at every time period or interval in the data transfer. 

20 It is to be noted that the present invention is not limited to the use of Voice 

XML, but can be used with any scripting language that executes at the system 

platform or interpreter. 

Further, in addition to being used in voice network appUcation, the above 
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embodiment can also be used in data transfer applications in a similar fashion. 
However, in the preferred embodiment, if the data transfer is incomplete and 
results in useless information to the wireless device 12, the billing system (i.e. 
prepaid server 34) is triggered to not bill for the connection time, as the data 
5 transfer was unsuccessful. 

Further, it is contemplated that this embodiment of the present invention can 
be coupled with any or all of the embodiments previously discussed. For example, 
before a data transfer occurs a cost for the transfer is calculated or estimated, and 
the prepaid server 34 determines whether or not sufficient "tokens" exist in the 

10 appropriate accoxmt before the data transfer is allowed to continue. When the 

prepaid server 34 determines that the transfer can continue, the above embodiment 
can be incorporated to monitor the actual connection time, thus allowing the 
prepaid server 34 to determine whether or not the actual connection time exceeds 
the calculated or estimated amount and intermpts the transfer or connection when 

1 5 such an event occurs. 

It should be finally noted that the above aspects of the present invention are 
not limited to prepaid billing systems, as previously described, but can be used in 
any IVR system where there is the possibility for a voice/data connection record to 
be lost when a failure occurs in the server or system handling the connection, nor is 

20 the present invention limited to wireless communication systems. 

It will be appreciated that the above descriptions are intended only to serve 
as examples, and that many other embodiments are possible within the spirit and 
the scope of the present invention. 
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WHAT IS CLAIMED IS: 
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1 . A method for providing prepaid data transfer service, the method 
comprising: 

(a) receiving a request for data; 

(b) calculating a cost of providing the data; and 

(c) determining whether a sufficient amount to cover said cost is 
available in an account. 

2. The method of claim 1, further comprising: 

(d) initiating the data transfer service if said sufficient amount is 
available. 

3. The method of claim 2, further comprising: 

(e) blocking the data transfer service if said sufficient amount is not 
available. 

4. The method of claim 3, further comprising: 

(f) sending a message or said data to a wkeless device. 

5. The method of claim 4, wherein said message comprises a recharge 

URL. 
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6. The method of claim 1 , wherein (b) is performed by calculating said 
cost according to at least one of an amount of data required for the data transfer 
service, a type of data and an identity of a data source for providing the data, the 
date and time of the data transfer, and the subscriber's class of service. 

7. The method of claim 6, wherein (b) ftirttier comprises: 

(i) calculating a cost of the data ti ansfer service in an arbitrary unit; and 

(ii) converting said arbitrary unit into a charge to said prepaid account of 
the subscriber. 

8. The method of claim 7, wherem (ii) is performed according to at 
least one of the date and time of tiie data transfer, and a class of service for the 
subscriber. 

* 9. The method of claim 8, wherein said class of service is defined 
according to at least one rule for each subscriber. 

1 0 . The method of claim 8, wherein (i) is performed according to at least 
one of an amount of data requked for the data transfer service, a type of data and 

an identity of a data source for providing the data. 

1 1 . The method of claim 1, wherein (b) comprises: 

(i) calculating a cost of the data transfer service in an arbitrary unit; and 

29 



wo 02/067600 PCT/US02/01243 

(ii) converting said arbitrary unit into a charge to said prepaid account of 
the subscriber. 



12. The method of claim 1 1, wherein said arbitrary unit is set with an 
expiration time. 

13. The method of claim 12, wherem after said expiration tune said 
arbitrary units are converted into a second charge to said prepaid accoxmt, wherein 
said second charge has a different value than said charge. 

14. The method of claim 12, wherein said expiration time is a function of 
at least one of the date and time. 

15. The method of claim 1, wherein a sufficient amount is determined as 
an amount in said prepaid account above a minimum negative balance threshold. 



16. The method of claim 1, further comprising: 

(d) calculating an actual cost for performing the data transfer service; 

and 

(e) obtaining payment from said prepaid account of the subscriber. 

17. The method of claim 16, wherein (d) is perforaied only after the data 
transfer service is complete. 

30 



wo 02/067600 PCT/US02/01243 

18. The method of claim 16, wherem (d) is perforaied as the data transfer 
service is being performed. 

19. The method of claim 1, further comprising: 

(d) transmitting said data; and 

(e) monitoring an actual cost of transmitting said data. 

20. The method of claim 19, wherein said monitoring occurs at a set 
interval during transmitting of said data. 

21. The method of claim 19, further comprising: 

(f) blocking said the data transfer if said actual cost exceeds said 
calculated cost. 

22. The method of claim 1, further comprising: 

(d) denying a service user, having a class of service, from receiving said 
data if said sufficient amount is not available, wherein said denial is based on at 
least said user's class of service. 

23. A method of providing a prepaid data transfer service, the method 

comprising: 

(a) receiving a request for data; 
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(b) estimating a cost of providing said data; 

(c) determining whether a sufficient amount to cover said estimated cost 
is available in an account; 

(d) initiating the data transfer service if said sufficient amount is 
available; and 

(e) monitoring an actual cost of the data transfer service during the data 
transfer service. 



24. The method of claim 23, wherein said monitoring occurs at a set 
interval during said data transfer service. 



25. The method of claim 23, further comprising: 

(f) blocking the data transfer service is said actual cost exceeds the 
estimated cost. 

26. A system for providing a prepaid data transfer service to a subscriber 
of data from a data source, comprising: 

(a) a communication device for operation by the subscriber; 

(b) a data network for connecting said communication device to the data 
source; and 

(c) a prepaid system for being connected to said data network and said 

communication device, for determining a cost for transferring the 

data to said communication device and for storing a subscriber 
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accomt, said subscriber account having a prepaid amount, such 1hat 
said prepaid system determines whether to permit the data transfer 
service according to a comparison of said cost aad said prepaid 
amount in said subscriber account. 

27. The system of claim 26, wherein said prepaid system comprises: 

(i) a data monitor connected to said data network for monitoring data 
traffic over said data network, including a request firom said 
cormnunication device for the data transfer service, and for 
calculating said cost; and 

(ii) a prepaid server for managing said subscriber account and for 
determining whether to authorize the data transfer service according 
to said comparison between said cost and said prepaid amount. 

28. The system of claim 27, wherein said data monitor calculates said 
cost in arbitrary units, and said prepaid server converts said arbitrary imits into an 
actual amoimt for debiting said subscriber account. 

29. The system of claim 28, wherein said arbitrary units are set with an 
expiration time. 



30. The system of claim 29, wherein after said expiration time said 

prepaid server converts said arbitrary units into a second actual amount for debiting 
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said subscriber account, wherein said second actual amount is different than said 
actual amount. 



3 1 . The system of claim 29, wherein said expiration time is a function of 
at least one of the date and time. 

32. The system of claun 26, further comprising: 

(d) a voice network in communication with said prepaid server, such that 
said prepaid server also determines whether to authorize a voice 
service according to a comparison between a cost of said voice 
service and said prepaid amount. 



33. The system of claim 26, wherein said prepaid system monitors a 
connection between said communication device and said data source 
at a preset interval and determines an actual cost of said connection 
during said connection at each occurrence of said interval, such that 
said prepaid system determines whether to permit the data transfer 
service according to a comparison of said actual cost and said prepaid 
amount in said subscriber account. 

34. The system of claim 32, wherein said prepaid system monitors a 

connection between said communication device and at least a second 

wireless device connected to said voice network at a preset interval 
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and determines an actual cost of said connection during said 
connection at each occurrence of said interval, such tliat said prepaid 
system determines whether to continue said connection between said 
communication device and said second communication device 
according to a comparison of said actual cost and said prepaid 
amount in said subscriber account. 

35. The system of claim 26, wherein said commimication device is a 
wireless communication device. 

36. The system of claim 26, wherein said communication device is a 
wireline communication device. 

37. A system for providing a prepaid data transfer service to a subscriber 
of data from a data source, comprising: 

a prepaid system, wherein said prepaid system determines a cost for 
transferrmg data and stores a subscriber account, said subscriber account having a 
prepaid amount, such that said prepaid system determines whether to permit the 
data transfer service according to a comparison of said cost and said prepaid 
amount in said subscriber account. 

38. The system of claim 37, further comprising a conununication device 

for operation by said subscriber. 
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39. The system of claim 37, further comprismg a data network for 
comiectmg a communicating device to the data source. 
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